For purposes of designing and testing an electronic circuit, it is useful to simulate performance of the electronic circuit. Simulation of an electronic circuit may be accomplished using a simulation program implemented by a computer system. Such simulation programs are particularly useful in simulating performance of semiconductor integrated circuits including application specific integrated circuits (ASIC's). One example of several commercially available simulation programs is Verilog-XL available from Cadence corporation of Mountain View, Calif. Another example of a simulation program is a VCS simulator available from Chronologic Corporation.
Simulators are commonly employed to simulate performance of an electronic circuit as coupled to other external devices such as, for example, an extension bus of a computer. A virtual test bench is a simulation construction including simulation models of a device under test (DUT) and simulation models of external devices with which the DUT interfaces. A Verilog-XL simulator may be used for effecting simulation of a virtual test bench wherein the virtual test bench is described by a hardware description language. On example of a hardware description language is the Verilog hardware description language which is commonly used to describe a test bench for input to a simulator.
With reference to FIG. 1, a block diagram is shown of a host computer system 112 for implementing a simulator. In general, host computer system 112 for implementing a simulator comprises a bus 100 for communicating information. A host processor 101 is coupled with bus 100 for processing information and commands. A computer readable volatile memory unit 102 (e.g. random access memory unit) is coupled with bus 100 for storing information and commands for host processor 101. A computer readable non-volatile memory unit 103 (e.g., read only memory unit) is coupled with bus 100 for storing static information and commands for host processor 101. A computer readable data storage device 104 such as a magnetic or optical disk and disk drive is coupled with bus 100 for storing information and commands. A display device 105 is coupled to bus 100 for displaying information to the computer user. The display device 105 can be a liquid crystal device, cathode ray tube, or other display device suitable for creating graphic images and alphanumeric characters recognizable to the user. A simulator program and Verilog description of a test bench may be stored in memory units 102, 103 or in memory storage device 104 of host computer system 112.
FIG. 2 shows a block diagram illustrating a file structure organization 200 for organizing a virtual test bench according to prior art methods. A shell script 202 typically includes environment files, preprocessing files, simulator command line arguments, and post-processing files. Shell script 202 is used to execute a virtual test bench. Shell script 202 sets environmental variables. A simulator call 204 includes simulator command line arguments executed by shell script 202. Simulator command line arguments typically include library files, library directories, and a test stimulus file 206. Simulator call 204 is used to launch the simulator. Simulator call 204 defines and calls other files including the Verilog libraries and directories. Test stimulus file 206 includes information specific to a test run. Test stimulus file 206 also typically includes a prior art test bench file 208.
With reference to FIG. 3, a typical prior art virtual test bench 300 is shown. Virtual test bench 300 is instantiated by test stimulus file 206 of Simulator command line 204 (FIG. 2) and executed using shell script 202. Virtual test bench 300 may include an integer number, n+1, of virtual modules 302, 304, 306, 308, and 310 which are used to model structures and functions of simulated devices. Module 302 is a device under test module (DUT module). Module 304 is a model-0 module. Module 306 is a model-1 module. Module 308 is a model-2 module. Model 304 is a model-N module. As examples, each of modules 304, 306, 308, and 310 may be a host memory of a computer system hosting DUT module 302, a PCI bus arbiter of a computer system, or a physical interface for an ethernet chip (a Phy chip).
In virtual test bench 300, modules 302, 304, 306, 308, and 310 are interconnected by interconnections 316, 318, and 320. Interconnection 316 interconnects model-0 module 304, model-1 module 306, and DUT module 302. Interconnection 318 interconnects model-1 module 306 and model-2 module 308. Interconnection 320 interconnects model-N module 310 and model-1 module 306. Each of interconnections 316, 318, and 320 is integral to the Verilog description of test bench 300. In the prior art, interconnections 316, 318, and 320 are created and edited using Verilog syntax only. In order to change interconnections 316, 318, and 320, Verilog test bench files may be edited. Editing Verilog test bench files presents problems because Verilog testbench files are complex and may be located in many different places. For example, DUT module 302 files may be stored in a first directory while files for another module are stored in a second directory.
Each of models 302, 304, 306, 308, and 310 may include Verilog parameters. Parameters are defined locally within models 302, 304, 306, 308, and 310 but may be assigned values from outside of models 302, 304, 306, 308, and 310. Virtual test bench 300 includes a parameter assignment block 312 which configures modes of simulation by setting parameters such as, for example, a virtual memory size or a functional mode which a Phy chip is working in. Virtual test bench 300 may include Verilog macros 314. Verilog macros 314 are a text-substitution facility of the Verilog language. Each macro of Verilog macros 314 is a globally defined entity. A Verilog macro 314 may be defined in any Verilog file and may be referenced by any Verilog file provided that the simulator parses the definition of the Verilog macro 314 before any reference to that Verilog macro 314.
Simulators typically allow for configuring a test bench 208 in many different ways. This allows a user to simulate different design levels, to set model parameters, to connect different models, to define macros, and to select simulators. Typically, many files located in many different directories are used to describe a test bench 208. Each Verilog test bench file typically includes many nested conditional blocks. A test bench 208 defined by a large number of files, each including many nested conditional blocks in the Verilog code, tends to become very difficult to manage.
Verilog does not provide the convenience of grouping a collection of signals together into an entity as is desirable in some cases. A PCI bus is an example of a plurality of signals which may desirably be handled in simulation as a single entity, to facilitate the connection of devices to the bus. It may also be desirable to modify the way different devices connect to the same bus, for example to connect different devices to different slots of the PCI bus. Because typical prior art methods of managing a test bench provide no mechanism for grouping a collection of signals together into an entity, switching an interface of the DUT to a different slot may require extensive editing of many files.
FIG. 4 illustrates an example of files of a virtual test bench stored in separate directories. DUT module model file 302 (FIG. 3) is stored in a first directory. Module1 model file 306 is stored in a second directory. Module2 model file 308 is stored in a first sub directory of the second directory and Verilog macros 314 are stored in a third directory.
In order to change an interconnect 316, it is necessary in the prior art to edit the testbench module. This task typically requires; (1) transferring the testbench file to a local directory from a separate directory where it is stored, and (2) changing arguments in the Simulator command line to point to the new file. To make a change in a file, it is also often necessary to change corresponding argument files including, for example, library files, library directory files, and test stimulus files. Further, it is often necessary to edit certain additional files containing to change pointers.
Typical prior art methods of organizing a test bench require a minimum two or three files to implement a simulation process. Separate files are typically required for stimulus information, shell script information, and macro information. Therefore, transfer of fields from one engineering stage to another may be cumbersome.
What is needed is a method for managing a virtual test bench in which all simulation configuration is controlled at a central point, locally on a command line at run-time. What is also needed is a method for managing a virtual test bench in which configuration is controlled by issuing commands to modify a master setup file, and not by rigorous editing of a master setup file. In addition it would be advantageous to encapsulate a test stimulus file and testbench configuration into a single file because it is necessary to pass a virtual test bench from one stage to another in various phases of simulation construction. What is further needed is a method for managing a virtual test bench in which there is no need for complex editing of multiple components with conditional blocks of code. Finally, it would be advantageous if common configuration options could be reduced to command-line switches.